I think the number of changes that are occuring to make the openai model compatible with other models is starting to go too far, divergence starts to seem inevitable. We should look to make it easy to extend the openai model support for different dedicated variations with minimal code, as compared to the current full blown cut and paste approach. Moving this to the RC1 release so that we can better support deepseek as it's own first class model.

I think the number of changes that are occuring to make the openai model compatible with other models is starting to go too far, divergence starts to seem inevitable. We should look to make it easy to extend the openai model support for different dedicated variations with minimal code, as compared to the current full blown cut and paste approach. Moving this to the RC1 release so that we can better support deepseek as it's own first class model.

Hi @markpollack

Thanks for the feedback on the PR—makes total sense.

Just to make sure I fully understand your intention before moving forward—are you suggesting that instead of adapting the existing spring-ai-openai module for DeepSeek compatibility, we should treat DeepSeek as its own first-class model (like spring-ai-mistral-ai, spring-ai-moonshot, etc.) and place it under models/spring-ai-deepseek or something similar?

Let me know if that’s the direction you had in mind, or if you’d prefer another approach. Once confirmed, I’m happy to take the lead on the implementation.

Thanks again!

When using OpenAI compatibility mode, some models may extend the protocol, and the rapid development of large models makes it difficult for frameworks like Spring AI to adapt quickly and flexibly. Is there a better way to achieve a permanent solution?
Examples:

1. DeepSeek added a reasoning_content field.
2. QianFan finish_reason field add a new type normal, but since the type is fixed as ChatCompletionFinishReason, it causes serialization failures.

Hi @apappascs

yes, you understood me correctly.

Please take a look at the comment here - #2116 (comment)

and let me know how you want to proceed. As I'm going through the issues and doing triage, I see more and more of these deepseek issues that suggest it may take a bit of time to get the implementation stable in time for RC1 next May 13

I suggest first going into the spring-ai-community and then moving it over into spring-ai once it matures.

@mxsl-gr

Hi @markpollack,

Thanks for confirming.

I’ll get started on it. I believe we can have the implementation ready directly in spring-ai before the RC1 deadline on May 13. The spring-ai-community route does seem like a safer fallback if needed, but the goal is to have it solid enough to go straight into the main project.

@apappascs it seems like a community project to get active incubation and feedback would be the most effective route. I suspect we will eventually need a ReasoningClient as well - will be interesting to see how it turns out.

https://github.com/spring-ai-community/community/issues

@mxsl-gr @apappascs There is now a deepseek model in spring ai to handle this without interfering with the OpenAiChatModel. Closing this as any changes should be in that part of the code base.

thanks!